Technological innovations and developments in distributed computing systems and applications have led to a significant increase in the amount and variety of network computing devices and peripheral (hardware) devices that can be interconnected and remotely accessible over communications networks. In general, the functions of network devices can be accessed and controlled by client applications through some type of device interface. For example, a common approach for enabling application access and control of a multi-function device is by use of “virtual device interfaces” in which various functions of the device are exposed through discrete interfaces, where each virtual device interface is an abstraction of actual device functionality. A fundamental goal for a virtual device interface framework is to allow for generic device control code within the application which lends itself to specialization, (the grouping and segregation of specific functional domains), and to the ability of substituting “plug-in” simulators in lieu of the actual device interface. Indeed, it is preferable for the device interface code to maintain a strict hierarchal base that segregates discrete functional (virtual) device types and, thus, the APIs, which leads to more “code reuse,” and standardized APIs.
As multi-function devices become more complex, however, the ability to abstract device functionality becomes more problematic at the level of both device interface development and application development, especially when deterministic behavior is required. For example, challenges that are faced at the device interface level include: 1. Mode selection—Operations for each of the discrete functionalities often require switching modes of operation with resulting increased complexity; 2. Priority inversion—The operation of a functional block of low importance preempting the operation of another functional block of higher importance; and 3. Increased complexity of device API.
Conversely, when developing an application that must make use of a device interface which combines several functionalities, the application developer is often required to “understand” the multi-function behavior of the “special device.” A common approach to addressing this issue is to create an interface to the interface; one that must be “understood” at the user application level of operation. This direct method is problematic for various reasons. The most obvious being that the client application must include knowledge about a specific device type rather than a set of virtual device types. Ultimately, this knowledge leads to a mass of specialized device-specific code that should not be part of the application domain. In short, the application developer must include the “how” (knowledge of the device control) with the “what” (desired device behavior), which is not desirable. In addition to the application developer becoming responsible for device control issues, this approach inevitably introduces procedures that are tailored to a specific device, and many problems are only exposed when the application must be modified to make use of another device, (or set of devices), to accomplish the same task.
As the desired approach is to develop applications with “virtual device” interfaces, it is up to the device interface developer to provide the independent, yet integrated, functionality of the complex device. However, this often requires independent control channels for I/O, which are sometimes unavailable. For example, most video servers present two completely independent functions: 1) a “transport” (play/record functionality), and 2) a media management functionality. An interface user, (a scheduling/playout application), may want to manage the resources using a “system interface” and also cue and play clips using transport interfaces. That is, from the prospective of the client application, there are two (or more) discrete functionalities provided by separate devices. This interface scheme reduces the complexity of each device interface by restricting the problem domain to that of a single functionality, and thereby presents an opportunity to model the interface, and the client application, in an object orientated manner. However, this approach often presents a problem when independent control channels for I/O are not available for each operating device interface or when the target device limits the communication by its protocol implementation and/or by its physical/logical connections.
For example, the LOUTH (VDCP) protocol consists of a mixture of system (resource) and control (transport) commands. A VDCP device, therefore, provides several play/record (control) ports and a system port. However, the system port is only accessible via a control port. Thus, the interface developer is faced with the dilemma of having to present itself as both a “VTR” and a system resource manager. This complicates the interface by forcing modes of operation with priority impacts, and also complicates the application making use of the interface by requiring a knowledge of which interface is the system port.
Moreover, several major problems with the development of multiple device interfaces when they all operate on a single (physical) device communication connection, as each interface competes for a limited amount of communication, (and CPU), bandwidth. Device interfaces often operate in a quiescent state of “ready” with bursts of “high priority” and time critical activity. When more than one of such interfaces is operating simultaneously, there must be a way to arbitrate both, the maximum usage of the limited communications bandwidth, and the precise timing of time-critical messages, often at a “sub-field” resolution. These requirements present three major problems for device interface development, namely, 1. avoidance of process/thread priority inversion or contention; 2. precise timing of certain control messages; and 3. handling timing collisions for multiple control messages.
Priority inversion refers to the problem of a high priority interface executing a low priority task and taking precedence over a lower priority interface executing a high priority task. Dealing with priority inversion issues is difficult even in a real time operating system where process/thread priorities allow adjusting priorities. Indeed, priority adjustment at runtime is a very difficult and seldom successfully used method for handling the problem of multiple interfaces with bursts of “high priority” activity.